Crédits : JJ Ying (Unsplash) Une société chinoise avait racheté le site Polyfill.io et le service qui y était hébergé, utilisé par de nombreux sites. Son usage a été détourné, allant des contenus pornographiques à la diffusion de malwares. Depuis, plusieurs domaines ont été suspendus et des entreprises comme Cloudflare et Google sont intervenues.
Un polyfill est un morceau de code, souvent écrit en JavaScript, utilisé pour fournir des fonctionnalités récentes à d’anciens navigateurs. Une technique utile depuis longtemps pour s’assurer que les internautes ont tous au moins les fonctions de base, même depuis des appareils anciens. Même si leur usage baisse graduellement, on les trouve encore dans des centaines de milliers de sites.
Le site Polyfill.io était particulièrement connu. Il avait été construit pour être une vaste bibliothèque de polyfills, afin que chaque développeur trouve son bonheur. En février cependant, le nom de domaine et compte GitHub ont été rachetés par l’entreprise chinoise Funnull.
Le créateur du projet, Andrew Brett (employé chez Fastly), recommandait alors de supprimer immédiatement toutes les références à Polyfill.io. Il ajoutait que son usage n’était plus nécessaire, les nouvelles technologies étant rapidement adoptées par tous les navigateurs.
Tout s’enchaine rapidement
Abonnez-vous pour tout dévorer et ne rien manquer.
Déjà abonné ? Se connecter
Commentaires (15)
#1
C'est pour ça que je râle à chaque fois que je vois un reCaptcha (ou équivalent) sur une page d'identification. Ça a été le cas pendant très longtemps sur ÉDF par exemple.
Alors j'imagine qu'ils utilisent Subresource Integrity, mais je ne suis pas allé vérifier à chaque fois.
#2
C'est un vœu pieux, mais ne pas utiliser un marteau pour écraser une mouche est une bonne habitude.
#2.1
Le SCA a de beaux jours devant lui.
#2.2
La grosse différence entre les deux ? D'un côté, tant qu'il n'y a pas eu récupération des dépendances depuis le site polyfill aucun soucis (pour schématiser pour les connaisseurs, pas de npm install). La faille peut se propager, mais il faut une action (mise à jour du site).
Pour l'autre, un site, sans rien faire, devient vulnérable du jour au lendemain.
#2.3
C'est acceptable pour des petits projets à durée de vie très courte, pour de la preuve de concept, mais ça s'arrête là.
Que des .gov ou des grands comptes utilisent ce type de cdn, cela me laisse dubitatif.
#3
#4
Je ne sais pas si ça à changé maintenant mais ce serait une bonne idée de faire attention de charger que ce qu'il faut.
Et réflexe du vieux ex-dev, charger une bibliothèque pour en utiliser 2 fonctions simples à coder, voir dont le code est trouvable, ben j’optai toujours sur la solution dont j'avais la maitrise. Mais ce comportement n'existe que dans de très rares cas à des fin de forte optimisation ou de sécurité aujourd'hui.
#5
Ou tout coder soi même (ce qui semble vraiment compliqué) ?
#5.1
Après, dans tous les cas, on est pas censé mettre en prod de "latest", que ce soit des images de container ou des versions d'une bibliothèque. C'est une affreuse perte de maîtrise et un gros risque à s'exposer à des breaking changes quand ce ne sont pas des problèmes de sécu comme ici.
La supervision des mises à jour, ça s'automatise comme un rien. Les gestionnaires le font eux-même et des outils comme Dependabot chez GitHub le gèrent aussi. Et dans le cas des libs importées comme ça depuis l'extérieur, à mes yeux c'est une pratique aux antipodes de la sécurité. À voir aussi si les solutions SAST/SCA les vérifient ou non, j'ai un doute là dessus mais cela serait un minimum.
Historique des modifications :
Posté le 06/07/2024 à 10h54
Comme indiqué par @Glandos en #1, il existe déjà des mécanismes indiquant qu'on facile un checksum pour la bibliothèque chargée à distance.
Après, dans tous les cas, on est pas censé mettre en prod de "latest", que ce soit des images de container ou des versions d'une bibliothèque. C'est une affreuse perte de maîtrise et un gros risque à s'exposer à des breaking changes quand ce ne sont pas des problèmes de sécu comme ici.
La supervision des mises à jour, ça s'automatise comme un rien. Les gestionnaires le font eux-même et des outils comme Dependabot chez GitHub le gèrent aussi. Et dans le cas des libs importées comme ça depuis l'extérieur, à mes yeux c'est une pratique aux antipodes de la sécurité. À voir aussi si les solutions SAST/SCA les vérifient ou non, j'ai un doute là dessus mais cela serait un minimum.
#6
#6.1
Perso, juste avec du CSS et du HTML j'ai pu faire des templates Hugo qui ont des éléments interactifs comme un carrousel, déplier / replier des informations, et afficher des petites pop-up sur un "?".
Le seul élément JS que j'ai fini par mettre, c'était pour intégrer un fil Mastodon depuis le flux RSS de ce dernier.
Tout ceci me semble être la solution de facilité sacrifiant sur cet autel la maîtrise et la sécurité.
Historique des modifications :
Posté le 07/07/2024 à 10h44
J'ai l'impression que les dev web ne savent plus rien faire sans devoir importer 3 tonnes de lib javascript pour faire des pages web de 4 lignes de texte et deux images qui vont 45Mb.
Perso, juste avec du CSS et du HTML j'ai pu faire des templates Hugo qui ont des éléments interactifs comme un carrousel, déplier / replier des informations, et afficher des petites pop-up sur un "?".
Le seul élément JS que j'ai fini par mettre, c'était pour intégrer un fil Mastodon depuis le flux RSS de ce dernier.
Tout ceci me semble être la solution de facilité sacrifiée sur l'autel de la maîtrise et de la sécurité.
Posté le 07/07/2024 à 10h45
J'ai l'impression que les dev web ne savent plus rien faire sans devoir importer 3 tonnes de lib javascript pour faire des pages web de 4 lignes de texte et deux images qui vont 45Mb.
Perso, juste avec du CSS et du HTML j'ai pu faire des templates Hugo qui ont des éléments interactifs comme un carrousel, déplier / replier des informations, et afficher des petites pop-up sur un "?".
Le seul élément JS que j'ai fini par mettre, c'était pour intégrer un fil Mastodon depuis le flux RSS de ce dernier.
Tout ceci me semble être la solution de facilité sacrifiant sur cet autel la maîtrise et la sécurité.
#6.2
#6.3
#6.4
Mais ce que j'ai le plus constaté, c'est qu'en réalité l'optim vient plutôt des coûts. Quand ceux-ci ne sont plus invisibles, on prend conscience qu'une bécane overkill pour faire tourner deux pauv' appli ça coûte très cher. Et je ne parle pas que de la facture du CSP
Historique des modifications :
Posté le 08/07/2024 à 08h14
J'avoue que le Green IT est une notion qui me fait sourire, car une bonne partie de ses éléments ne sont rien d'autre que de la bonne vieille optimisation qu'on a laissée derrière en se disant "pas grave, j'ai 3TB de RAM et 76CPU faut que ça serve". Et au final elle est tout autant ignorée parce que dans la tête de beaucoup, ce n'est que de la "bonne conscience".
Mais ce que j'ai le plus constaté, c'est qu'en réalité l'optim vient plutôt des coûts. Quand ceux-ci ne sont plus invisibles, on prend conscience qu'une bécane overkill pour faire tourner deux pauv' appli ça coûte très cher.
#7
Du coup, mes applis sont moches, semblent vieilles, mais ... elles fonctionnent internet coupé.
Ma dernière découverte (car au boulot nos sites DMZ n'ont par défaut pas le droit d'aller sur internet): Wordpress dépend d'internet, mais ses plugins, c'est pire! Et encore, quand ce n'est pas le presta lui-même qui héberge des scripts chez lui.
Vivement NIS2!
Historique des modifications :
Posté le 08/07/2024 à 10h07
J'ai une politique no-CDN en dev. Et très forte limitation des dépendances (quand on arrive à suivre qui dépend de qui...).
Du coup, mes applis sont moches, semblent vieilles, mais ... elles fonctionnent internet coupé.